[レポート] Migrating to the cloud: What is the cost of doing nothing? (ENT325) #reinvent

大家好，AWS事業本部の西野です。 タイトルに引かれて視聴してみたセッションのレポートをします。

動画

概要

Are you considering migrating to AWS? Organizations of all types and sizes are migrating to AWS at record speeds. Learn about the top migration trends and insights, gathered by analyzing more than 2,000 of the largest AWS migrations and modernizations. Discover what successful migrations have in common and what decisions lead to the greatest outcomes. See a comparison of real migration data against workloads that remain on premises, and deep dive into the cost of doing nothing. Hear from Marriott about how these approaches and insights made their cloud journey successful. Come learn how to make the best migration decisions, wherever you are in your journey.

セッション内容

お客様がクラウド移行をする理由

多くのユーザーがクラウドマイグレーションを選択するのはなぜでしょうか？ ビジネスの俊敏性・コスト・セキュリティ・障害からの復旧力など数多くの理由があげられると前置きした上で、Rallo氏は自らの経験を話すことから始めます。

2008年頃のRallo氏はコストコなどの大手小売業者向けにオンライン写真仕上げを行う会社を経営していました。

当時のインフラストラクチャーは最繁忙期である感謝祭（Thanksgiving Day）にあわせて調達されていたようで、1ドルの収益あげるために費やされるこのインフラストラクチャーのコストは35セントにものぼりました。 ビジネスが成長を遂げている間は問題がなかったものの、主要な大手小売業社を販売チャネルとして確保し終えた段階でコストが大きな懸念点になりました。

コンピューティングリソースの使用率に依存せず一定のコストが掛かり続ける状態を改善するため、まずはワークロードの分析から始め、やがてAuto Scalingの利用を開始しました。
このことが財務体質の改善につながりファンドからの融資受け入れにもつながったそうです。

数多くのクラウド移行による教訓

後にAWSに入社したRallo氏は、多くのお客様を支援するなかでいくつかのことを発見します。

まず初めに、マイグレーションの規模完了までの早さには相関が無いことです。
画像の中の丸はマイグレーションの規模を表しており、小さいものが小規模、大きいものが大規模です。
それでは、いったい何がマイグレーションの速度を決定づけるのでしょうか？それは、マイグレーション・アセスメントの実施有無です。

ここで言われていたマイグレーション・アセスメントは移行対象リソースの棚卸しやワークロードの分析、オンプレミス対AWSのコスト比較などを指します。

これらのアセスメントを事前に行っていたマイグレーションは比較的早期に完了する傾向にありました。画像の中の紫色の丸が何らかの形でアセスメントを実行したマイグレーションです。

また、単にオンプレミス環境をEC2に置き換えるだけではなく、数多くのAWSサービスの利用を試みたお客様の方が早期にマイグレーションを完了させたそうです。面白いですね。

加えて、AWSプロフェッショナルサービスを利用しているか、あるいはトレーニングを活用してチームおよびスタッフを教育していた場合マイグレーションの完了が早かったそうです。これは納得です。

「何もしないこと」のコスト

クラウドマイグレーションのトピックとしまず始めに上がってくるのがコストです。
AWSの利用によりインフラストラクチャーを固定資産から変動費へと転換でき、多くのお客様のケースにおいて当該インフラストラクチャーを自身で所有するより安く利用できます。AWSの規模の経済があるからです。
また、AWSの場合柔軟性が高く、ビジネス状況の要求に応じて利用したいときにいつでも利用できます。オンプレミス環境のときに必要だった調達から導入までのプロセスが不要になるので、コスト削減のみならずこのプロセスに関与する人々の時間まで節約できます。

Rallo氏の経験によれば、お客様環境に存在する少なくとも20%のサーバーは「ゾンビサーバー」（存在しているものの非稼働であるサーバー）だったそうです。

先述の通り、ビジネスの要求に応じて必要なリソースを確保しアプリケーションをデプロイできることがクラウドのメリットです。単なるコンピューティングリソースにとどまらず、200を超えるAWSサービス群がアプリケーション開発の迅速化に寄与します。

AWSの調査によれば、AWSを利用しているお客様はオンプレミスと比較して2.3倍の機能をリリースできたとのことです。

企業のブランドや利益を守るため、レジリエンスは重要です。 AWSを利用するとリージョンやアベイラビリティゾーンの仕組みによって全世界にデプロイ可能です。同等の仕組みが他のパブリッククラウドサービスにも存在しますね。

また、AWS Elastic Disaster RecoverやAWS Resilience Hubなどのレジリエンスを保つためのサービスが存在します。

セキュリティはAWSにとって常に最優先の事項です。 軍隊や世界規模の銀行など、セキュリティの要求水準が極めて高い顧客の要望を満たすよう作られています。

オンプレミスでシステムを稼働させる場合セキュリティのあらゆるレイヤーについてユーザーが責任を持たなければなりません。 しかし、AWSの場合、「責任共有モデル」があります。ハードウェアなどの物理的なレイヤーについてはAWSが責任を持つため、ユーザーはアプリケーションのセキュリティにのみ集中すればよくなります。 また、AWSはセキュアなアプリケーションを開発するためのツールやベストプラクティス、ガイダンスを提供しています。

マリオット・インターナショナル社のケース

ここからスピーカーがマリオット・インターナショナル社Haq氏に変わります。
マリオット・インターナショナル社は新型コロナウィルスの影響で収益が8−9割減少したことにより従量課金モデルへの転換・DXをより強く考えることになりました。 経済やパンデミックのような事象はコントロールできないが、ITインフラのCAPEXの削減はできるという考えのもと改革を進めていきました。

マリオット・インターナショナル社はクラウドへの移行を検討するにあたり、以下の３つの観点から要望をまとめました。

IT運用: 旧来型のオペレーション、つまりはリクエストにもとづく手作業をセルフサービスかつ自動化された方法に転換したかった
アプリケーション: モノリシックからイベント駆動・マイクロサービスアーキテクチャーにしたかった
インフラ: 資産としてのインフラから従量課金型で自由にスケールアップ・ダウンできるものにしたかった

これらの要求を満たしうるものこそがクラウド（AWS）でした。

クラウドによって得られるメリット（コスト削減、イノベーション、物理データセンターのリソース限界からの解消、技術的負債の修復）をすべて得ようとすると、結局は何も得られないことになるとHaq氏は強調します。 クラウド移行で最も重要なことは、クラウドによって企業が本当に求めていること、解決したいことが何であるのか特定・理解することです。

クラウド利用最適化のための前提条件としてHaq氏は３つの点をあげていました。

• 成功の基準を明確にすること
  • 何を最適化したいのか
• 共通のビジョンを定義すること
  • 組織全体として足並みを揃える
• シンプルさをキープすること
  • 過度に複雑なマルチクラウド・ハイブリッドクラウドの利用を避ける

クラウドによってスピード・自動化・コスト削減・スケーラビリティなどのメリットを享受できることはよく知られているかと思います。 ですが、クラウドによって他にも多くのメリットがあるとHaq氏は言います。

たとえば、クラウドの採用が組織全体の変化やイノベーションの触媒になりうることです。 クラウドネイティブサービスの採用によって開発スピードが早まると、開発者がより開発を効率化するよう志向するようになるそうです。 これはIT人材のスキルアップにもつながってゆきます。

続いてHaq氏は、クラウドが目的地ではなく行程（journey）に過ぎないことを強調します。 クラウドの採用後もKPIを構築することで継続的に経過観察に役立てることが重要です。

最後に、マリオット・インターナショナル社のクラウドジャーニーから得られた重要な教訓が紹介されます。

1つ目に、素早く計画を建てることです。

クラウド移行プロジェクト中で失敗を経験するかもしれませんが、重要なのはその失敗を受け入れる準備をしてくおくことです。 入念な計画が重要なことは否定しないものの、それが成功を約束するわけではありません。分析麻痺に陥らず、行動への志向性を持ち、まずはクラウドへの移行やモダナイゼーションのプロセスを始めてみる必要があります。

2つ目に、アプリケーションを合理化することです。

オンプレミスからクラウドへの移行によって手つかずの新しい環境を手に入れられます。この新たな環境に不要なデータや技術的負債を持ち込まないようにしましょう。ここでも、クラウド移行によって何を解決したいのかという問いが重要になってきます。

3つ目に、自ら立てた基準を頑固に守り抜くことです。

マリオットの場合、AWS環境で動かすシステムは必ずコンテナ化されているかもしくはAWSのネイティブサービスを使用することになっており、また、CI/CDパイプラインの実装が不可欠でした。一つの例外もなかったそうです。

4つ目に、一過性のコスト増を前もって計画しておくことです。多くのケースにおいて、企業はこの計画をもっていないため、コストが急増したときに始めて問題になります。オンプレミス環境とクラウド環境を並行稼働させる期間がある場合、その両方にコストがかかります。

5つ目に、自動化を始めから利用することです。自動化こそがクラウドのメリットです。

終わりに

このブログがほんの少しでも世界を良くできれば嬉しいです。
AWS事業本部の西野 (@xiyegen) がお送りしました。